DMARCレコードの段階的な導入を考えてみる

じゅんや

2023.01.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

DMARCとは

DMARCはRFC7489で標準化されているメール認証技術となります。
https://tex2e.github.io/rfc-translater/html/rfc7489.html

JPNIC様の以下のページが概要としては非常にわかりやすくまとまっておりますので
ご存じのない方は一度読んでみるのがわかりやすいと思います。 https://www.nic.ad.jp/ja/basics/terms/dmarc.html

ざっくりといえばこれまで受信側に委ねられていたSPF・DKIMの認証結果の取り扱いを送信側が指定するための技術です。

DMARCが存在しない場合、SPFやDKIMの認証が失敗した場合でもそのメールをどのように取り扱うかについては受信側に委ねられています。

no-dmarc-image

SPFやDKIMで不正かどうかの判断材料は受信側に提供はしているものの
不正な場合の挙動については受信側に任せるしかない状態でした。

DMARCを用いることでその指示を出すことがでるようになり
定義機能の範囲内であればこのように取り扱ってほしいという指示を出しその取り扱いを統一することができます。

exist-dmarc-image

なお図中では省略していますがDKIMに対しての評価も行われます。

送信側としてはDNSレコードの設定のみでよく例えば以下のようなメリットが得られます。

自ドメインのメールアドレスのなりすましメール被害の軽減(隔離・拒否ポリシーの利用)
社内利用であるが管理の漏れのある送信サーバを検出する(レポートの利用)

この記事について

受信サーバ側ではなく送信者側が設定するDNSレコードの設定を考える記事になります。

DMARCは導入するだけしているが必要以上に厳しいポリシーをかけてしまい
未着・迷惑メールとなるトラブルが多発という事例がみられます。　

SPFやDKIMのように値を設定したからOK！
ではなく適切に取り扱うのであれば何回か見直しておく方が良いものとなりますので設定例を踏まえて見直しの機会となっていただければと思います。

なお全てのパラメーターについて詳細に説明するわけではない点ご注意ください。

DMARCで対策できる範囲

DMARCはSPF・DKIMの認証結果を元にして判定を行います。

あくまで自ドメインがFROMに指定されたなりすましへの対策強化であり
例えば以下の事例には対応できません。

送信メールアドレスのドメインが自ドメインではないなりすましに対策をしたい
メール本文の内容を判定に利用した成りすまし・スパム対策をしたい

また受信サーバ側でDMARCへの対応が必要なので、
全ての受信者に適用されるわけではない点にはご注意ください。

段階を踏んだ導入をする

いきなり最終形を目指すのではなく
可能であればまずはレポートを受け取りつつ状況を把握・改善していきましょう。

いきなり隔離(quarantine)や拒否(reject)を割り当てると
SPFやDKIMの追加漏れ箇所から未着発生のトラブルが起きる可能性があります。

今回の一例とはなりますが以下のように徐々に厳しくしていく形が無難と考えます。

受信挙動を変えずレポート受信(必要であれば改善)
quarantine(隔離)ポリシーの適用
reject(拒否)ポリシーの適用

受信挙動を変えずレポート受信

そもそも導入するにあたりどの程度深刻な状態であるか(適用するだけの価値があるか)、
現状利用している範囲内でSPFやDKIMの設定漏れ等がないかを確認することが大切です。

とはいえ実際に迷惑メールや未着で確認するのもトラブルの種になるので、
現状から受信側の挙動を変えずDMARCのレポートの使用を利用して現状を把握します。

設定例

DMARCのレコードはサブドメイン_dmarcに対するTXTレコードに設定します。
(例: _dmarc.example.com)

"v=DMARC1 p=none rua=mailto:[email protected] ruf=mailto:[email protected]"

大雑把な意味合いとしてはメールの取り扱いを既存から変更せず(p=none)に集計レポート(rua)と失敗レポート(ruf)を[email protected]に送信する設定となります。

vタグはバージョン指定ですが現時点ではDMARC1のみですので、
現状は先頭に記載する必要のあるおまじないのようなものと思っていただいても良いです。

レポートについて

集計レポートは一定期間でどの程度認証が成功(Pass)しているのか失敗(Fail)しているのかを確認することができます。

失敗レポートは都度失敗した時の詳細な情報を受け取ることができます。
具体的にどのような失敗が存在するのかを確認したい場合はこちらを設定します。

このレポートで意図しない認証失敗がないかを確認し、
本来管轄ないであれば必要に応じSPFレコードの追加等の対応を行いましょう。

その他のレポートに関連するパラメータ

foタグ: 失敗レポートの対象となる認証条件(初期値: SPF・DKIMの両認証が失敗)
rfタグ: 失敗レポートのフォーマット(現時点ではafrfのみ対応)
riタグ: 集約レポートの報告周期(初期値: 86400(1日))

なおriの値は仕様上日時レポートが提供できることは必須であることが求められていますが
時刻レポートはベストエフォートでの対応となっている点は注意してください。

この段階で注意すべきこと

メールアドレスを公開するためそれに対して攻撃が行われる可能性がある点は注意が必要です。
RFC上でもこれについては言及されており(12.3参照)例えば以下のようなケースが考えられます。

不正なレポートの送付
- 用途と送信先が判明しているため偽情報のレポートが送信される可能性がある
失敗レポートを利用したDDoS等の攻撃
- 意図的に大量の失敗を引き起こしruf先に大量のメールを送信

各レポートは信頼できるサーバからのみのを確認するようにしましょう。

DDoSについては受信サーバ側(レポート送信側)で分間送信数の制限をかけるなど何かしらの対策をすることが推奨はされていますが、
仕様上必須とはなっていないためこういった攻撃を受ける可能性があるという点は考慮しておく必要があります。

対策や許容ができない場合は失敗レポートを受け取らないことも選択肢となります。

ただこの場合は具体的にどのようなメールが認証失敗しているか確認できないので
本当に管轄外のもので失敗しているのか管理抜けのものが存在しているのか確認が難しくなります。

quarantineポリシーの適用

概ね目処が付いたら実際に認証失敗外のメールに対してのアクションを設定していきましょう。

いきなり最も厳しいp=reject(拒否)をの適用は意図しない未着トラブルにもつながるため
まずはp=quarantine(隔離)を適用し様子を見るのがおすすめです。

quarantineは疑わしいものであると判断してもらうための値になります。

この"疑わしい"場合の挙動については明確に定義されていないため
受信サーバによりにスパムフラグがつく、迷惑メールボックスに入る等の厳密な挙動は定義されていないため注意してください。

設定例

# 例1: 認証に失敗したメールは隔離してレポートは受け取らない
"v=DMARC1 p=quarantine"

# 例2: 確率的(20%)に隔離ポリシーを適用し、意図しない認証失敗に対しての影響を抑えつつ様子を見る。レポートは集計だけ受け取る
"v=DMARC1 p=quarantine pct=20 rua=mailto:[email protected]"

pctタグはポリシーを適用する割合を設定するための値となります。
quarantineの場合は適用されなかったものとは通常通りの取り扱いになります。

注意すべき点としてpctタグはpタグで指定されたポリシーを適用する割合であり
集計・失敗レポートに対しては適用されません。

DMARCにおける認証失敗とは

認証に失敗し隔離ポリシーが適用されるケースというのはどのようなケースでしょうか。

これはSPFによる認証が失敗(pass以外)かつDKIMの認証が失敗した場合となります。
なおfoタグは失敗レポートにの対象設定となりポリシーに対する評価には影響しない点に注意してください。

SPFとDKIMの認証どちらかが合格すれば良いためDNSレコード以外にサーバに設定が必要なDKIMは見送りSPFのみでも適用可能ですのでご検討ください。

ただし認証要素が一つ欠けるため設定漏れ等のリスクが高まる点には注意してください。

rejectポリシーの適用

rejectポリシーはSMTPトランザクションレベルでの完全な拒否となります。
最終的にここまでできれば受信者側に自ドメインのなりすましを見せることなく信頼性を高くすることができます。

とはいえ迷惑メールに入っていないか確認してくださいで済む隔離と異なり
意図しない認証失敗はレコード再調整からの再送信等対応が大きくなる可能性があるので事前に十分に確認をしてください。

ここ何年かではリモートワークが進んでいる関係で開発機からの自アドレス宛のメール送信といった
不特定のIPからの送信というケースが出ているケースの阻害になる可能性もありますのでご注意ください。

逆にそういった利用をさせないためにあえてrejectを指定するのも一つの手かもしれません。

設定例

# 例1: 認証に失敗したメールは受信拒否、対象把握のために失敗レポートを受信する
"v=DMARC1 p=reject ruf=mailto:[email protected]"

# 例2: rejectとquarantineを半分づつに適用する。集計レポートは受け取る
"v=DMARC1 p=reject pct=50 rua=mailto:[email protected]"

rejectポリシーが設定されている場合、pctによりrejectの適用対象外となったメールについては
何もしないでは無くquarantineと同等の扱いとなる点は注意してください。

終わりに

今回はDMARCレコードの設定を実際の設定例と合わせ追っていきました。

送信側としてはDNSレコードの設定のみで導入への敷居は低いですが
SPFやDKIMのようにとりあえずこの値を設定しておけば成りすまし対策はOK！という設定はありません。

quarantineやrejectを設定して受信者の目につくなりすましを減らせるのが理想ですが
運用状況的に難しい場合もありますので集計レポートだけでも受け取っておくことも選択肢としてみてください。

備考: 実際のドメインにおける利用を見る

せっかくなのでいくつかのドメインでDMARCレコードの設定を確認してみました。

以下以外にも自分が利用しているサービスのドメインでも確認していますが
大きめのサービスではnoneでも集計レポートの受け取りを最低でも設定しているところが多く見当たりました。

レポートについては集計レポートは多くの場所が受け取っている一方、失敗レポートまで受信しているドメインは少数のようです。

#フリーメール系
dig +short _dmarc.yahoo.co.jp txt
"v=DMARC1; p=quarantine; rua=mailto:[email protected]"
$ dig +short _dmarc.gmail.com txt
"v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]"
## 未設定
$ dig +short _dmarc.live.jp txt | wc -l
       0

# ３大キャリアはいずれもnone設定
$ dig +short _dmarc.softbank.ne.jp txt
"v=DMARC1; p=none"
$ dig +short _dmarc.docomo.ne.jp txt
"v=DMARC1; p=none; rua=mailto:[email protected]"
$ dig +short _dmarc.ezweb.ne.jp txt
"v=DMARC1; p=none"

# 企業で利用しているドメインは厳しめの傾向あり
$ dig +short _dmarc.amazon.com txt
"v=DMARC1;" "p=quarantine;" "pct=100;" "rua=mailto:[email protected];" "ruf=mailto:[email protected]"
$ dig +short _dmarc.google.com txt
"v=DMARC1; p=reject; rua=mailto:[email protected]"
$ dig +short _dmarc.cloudflare.com txt
"v=DMARC1; p=reject; pct=100; rua=mailto:[email protected],mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]"

# なおクラスメソッドのドメインはDMARCは未設定です
$ dig +short _dmarc.classmethod.jp txt |wc -l
       0